| 27 | |
| 28 | == Files and File Paths == |
| 29 | === What do I do with `DATADIR`, `LOCALEDIR`, and `LIBDIR`? === |
| 30 | `DATADIR`, `LOCALEDIR`, and `LIBDIR` are defined as functions in the Windows build. Therefore, doing something like this will break the Windows build: |
| 31 | {{{ |
| 32 | printf("File in DATADIR is: %s\n", DATADIR G_DIR_SEPARATOR_S "pic.png") |
| 33 | }}} |
| 34 | |
| 35 | Instead, it should be: |
| 36 | {{{ |
| 37 | printf("File in DATADIR is: %s%s%s\n", DATADIR, G_DIR_SEPARATOR_S, "pic.png"); |
| 38 | }}} |
| 39 | |
| 40 | === Why are files opened with mode `b`? === |
| 41 | Without this, on Windows systems the opened files will use Windows default translation (<CR><LF> for newline, for example). This will cause errors due to newline format and the "bytes read" counts, which will be wrong when comparing the return value of `read()` to `stat()`. |
| 42 | |
| 43 | === Why are there `G_DIR_SEPARATOR_S` and `G_DIR_SEPARATOR` usages everywhere? === |
| 44 | This is a matter of maintaining cross-platform compatibility. Windows uses a backslash ("\") for directory separators in paths, while UNIX-like systems use the forward slash ("/"). Other OSes may choose to use other separators--for example, prior to Mac OS X, it was common for the directory separator on Macs to be a colon (":"). It is impractical to use preprocessor directives throughout the code to determine the path style to use, especially if a new OS were to appear and use a different directory separator. GLib, which we already use, provides the convenient separator macro, so we use this to reduce our code complexity and maintain cross-platform portability. |
| 45 | |
| 46 | == General == |
| 47 | === What should I do to get the contents of an environment variable? == |
| 48 | Use `g_getenv()`. |
| 49 | |
| 50 | === Should I use `snprintf()` or `vsnprintf()`? === |
| 51 | No. Use the GLib wrapper functions instead. They are `g_snprintf()` and `g_vsnprintf`. |
| 52 | |
| 53 | == Headers == |
| 54 | === Why is win32dep.h causing problems for me? === |
| 55 | You need to make sure it is the last header you include if you need to include it. Not doing so is asking for problems. |
| 56 | |
| 57 | == Plugins and Protocols == |
| 58 | === How should I handle global variables? === |
| 59 | Use `G_MODULE_IMPORT` for any global variable located outside your dynamic library. Not doing this will cause "Memory Access Violation" errors on Windows systems. |
| 60 | |
| 61 | === What should I do for "exported" functions? === |
| 62 | If your plugin has functions that are to be accessed from outside the scope of its file (.dll or .so), `G_MODULE_EXPORT` those functions. |